1. Field of the Invention
The present invention relates to computer graphics systems and, more particularly, to a computer graphics system utilizing a graphics accelerator having an enhanced logic and register structure to achieve enhanced performance.
2. Discussion of the Related Art
Computer graphics systems are commonly used for displaying graphical representations of objects on a two-dimensional video display screen. Current computer graphics display systems provide highly detailed representations and are used in a variety of applications. A computer graphics display system generally comprises a central processing unit (CPU), system memory, a graphics machine and a video display screen.
In typical computer graphics display systems, an object to be presented on the display screen is broken down into graphics primitives. Primitives are basic components of a graphics display and may include points, lines, vectors and polygons (e.g., triangles and quadrilaterals). Typically, a hardware/software scheme is implemented to render, or draw, the graphics primitives that represent a view of one or more objects being represented on the display screen.
Generally, the primitives of the three-dimensional object to be rendered are defined by the host CPU in terms of primitive data. For example, when the primitive is a triangle, the host computer may define the primitive in terms of the X, Y and Z coordinates of its vertices, as well as in terms of the red, green, blue and alpha (R, G, B and .alpha.) color values of each vertex. Alpha is a transparency value. Additional primitive data may be used in specific applications. Rendering hardware interpolates the primitive data to compute the display screen pixels that represent each primitive, and the R, G, B and .alpha. values for each pixel.
The graphics machine generally includes a geometry accelerator, a rasterizer, a frame buffer controller and a frame buffer. The graphics machine may also include texture mapping hardware. The geometry accelerator receives vertex data from the host CPU that defines the primitives that make up the view to be displayed. The geometry accelerator typically comprises a transform component which receives vertex data from the CPU, a clipping component, an illumination component, and a plane equations component. The transform component performs transformations on the vertex data received from the CPU, such as rotation and translation of the image space defined by vertex data. The clipping component clips the vertex data so that only vertex data relating to primitives that make up the portion of the view that will be seen by the user is kept for further processing. The illumination or lighting component calculates the final colors of the vertices of the primitives based on the vertex data and based on lighting conditions. The plane equations component generates floating point equations which define the image space within the vertices. The floating point equations are later converted into fixed point equations and the rasterizer and texture mapping hardware generate the final screen coordinate and color data for each pixel in each primitive.
The operations of the geometry accelerator are computationally very intense. One frame of a three-dimensional (3-D) graphics display may include on the order of hundreds of thousands of primitives. To achieve state-of-the-art performance, the geometry accelerator may be required to perform several hundred million floating point calculations per second. Furthermore, the volume of data transferred between the host computer and the graphics hardware is very large. Additional data transmitted from the host computer to the geometry accelerator includes illumination parameters, clipping parameters and any other parameters needed to generate the graphics display.
Various techniques have been employed to improve the performance of geometry accelerators. These including pipelining, parallel processing, reducing redundance, minimizing computations, etc. in a graphics accelerator. For example, conventional graphic systems are known to distribute the vertex data to the geometry accelerators in a manner that results in a non-uniform loading of the geometry accelerators. This variability in geometry accelerator utilization results in periods of time when one or more geometry accelerators are not processing vertex data when they are capable of doing so. Since the throughput of the graphics system is dependent upon the efficiency of the geometry accelerators, this inefficient use of the processing capabilities decreases the efficiency of the graphics system. In response to this shortcoming in the prior art, a solution was developed for distributing "chunks` of data to a parallel arrangement of geometry accelerators.
Another way of improving the throughput of a geometry accelerator is to minimize the overall amount of data that must be processed by it. For example, this can be done by minimizing redundancy in the data being sent to the geometry accelerator. Application program interfaces (APIs) are known to reduce redundant data sent to the geometry accelerator by identifying a "constant color" mode of operation. As is known, APIs generally interface higher-level software to hardware. In a specific area, APIs are known to interface software graphic routines coded, for example, in C programming language, to graphic hardware devices, such as a graphics accelerator.
To more particularly describe the identification of a constant color mode of operation, some APIs require the higher-level, programming software to include a color command associated with each primitive, or primitive vertex. Since a color command is associated with each primitive, or primitive vertex, it is a relatively straight-forward task to identify a constant color mode of operation. Namely, by identifying repeated use of the same color. Thereafter, the graphics API may implement a minimization of the parameters or information that it sends to the geometry accelerator.
Certain APIs are known to provide vertex programming modes. These modes indicated the type and quantity of data that is presented to the hardware for each vertex. For example, all vertices in a particular group might include X, Y, and Z data, while others might include X, Y, Z, and red, green, and blue (RGB) color data. However, all vertices in a given group are alike, insofar as all either have RGB data or none have RGB data. If no color data is present, this limitation permits hardware to easily identify a constant color mode and thus increase system performance by not computing slope information.
However, other graphic APIs do not require such a color command to be associated with the drawing instruction/command. For example, OpenGL is a widely used graphics API, which is rapidly becoming an industry standard. OpenGL offers a robust, yet flexible, programming interface, and does not require a programmer to include a color command with each graphic primitive. Instead, a color command need only be provided upon invoking a color change. Moreover, OpenGL provides two separate color commands: a "glColor3" command and a "glColor4" command. The glColor3 command includes parameters for the red, green, and blue (RGB) color components, and the .alpha. value defaults to 1 (no transparency). The glColor4 command includes parameters that not only specify the R, G, and B components, but also the .alpha. component.
In a graphics program coded in OpenGL, or any other graphics API that does not provide for the identification of a constant color mode, excessive graphics data/information is sent to the geometry accelerator. Processing this redundant information consumes an excessive amount of time and resources. For example, suppose a graphic program is drawing a picture of an automobile on the system display. The body of the automobile may be a uniform color, and yet may require thousands of graphic primitives to draw. If the geometry accelerator chip processes each primitive color independently, excessive time and resource allocation is required (e.g., calculations in the lighting machine and the plane equations for the primitive's color).
However, identification of such a "constant color" mode is not a trivial task. Since the geometry may receive a variety of graphic primitive types (e.g., vertices, line segments, triangle, quadrilaterals, triangle fans, triangle strips, etc.), the determination of whether or not to calculate plane equations for successive primitives/vertices is a difficult determination to make. Further complicating this determination within a geometry accelerator chip, as opposed to within the API, is the fact that some systems employ a plurality of geometry accelerator chips operating in parallel. If successive graphic primitives are processed by a different geometry accelerator, determination by a given geometry accelerator of whether or not to compute plane equation calculations, is a difficult determination to make.